home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1994 March
/
Internet Info CD-ROM (Walnut Creek) (March 1994).iso
/
inet
/
internet-drafts
/
draft-vaudreuil-smtp-stream-00.txt
< prev
next >
Wrap
Text File
|
1993-10-20
|
7KB
|
244 lines
Network Working Group Greg Vaudreuil
Internet Draft Tigon Corporation
Expires: 4/18/94 October 18, 1993
SMTP Service Extensions
for Command Streaming
<draft-vaudreuil-smtp-stream-00.txt>
1.Status of this Memo
This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas,
and its Working Groups. Note that other groups may also distribute
working documents as Internet Drafts.
Internet Drafts are valid for a maximum of six months and may be
updated, replaced, or obsoleted by other documents at any time. It is
inappropriate to use Internet Drafts as reference material or to cite
them other than as a "work in progress".
2.Abstract
This memo defines an extension to the SMTP service whereby an SMTP
client and server may negotiate the use of a command streaming
implementation model for SMTP. This model enables the batching of the
all commands between the EHLO and DATA command. This extension
significantly reduces the number of packets and round trips to send a
message. Batching the MAIL FROM and RCPT TO commands for multiple
receipients significantly decreases the protocol processing overhead
when sending messsages to multiple receipients.
3.Introduction
One source of inefficiency in the use of SMTP, especially when used in
in a central mail hub, is the implicit requirement to send the full
SMTP command stream, including each RCPT TO command sychronously, that
is, to wait for a response to the previous command before sending the
next. This stop and wait interaction often adds minutes to the length
of a SMTP session, partly when validation of addresses may require
non-local table lookup.
This memo uses the mechanism defined in [4] to define extensions to
the SMTP service whereby a client ("sender-SMTP") may declare support
for a atreaming command mode.
4.Framework for the Binary Extensions
The following service extension is hereby defined:
1) The name of the service extension is "Stream"
2) The EHLO keyword value associated with this extension is
"STREAM"
Internet Draft Expires 4/18/94
3) No parameter is used with the STREAM keyword
5.The Stream service extension
When a client SMTP wishes to submit (using the MAIL command) a content
body consisting of a MIME message containing arbitrary octet-aligned
material, it first issues the EHLO command to the server SMTP. If the
server SMTP responds with code 250 to the EHLO command, and the
response includes the EHLO keyword value STREAM, then the server SMTP
is indicating that it supports the command streaming implementation
model and will the batching of all commands between the EHLO and the
accept MIME messages containing arbitrary octet-aligned material.
After receiving the 250 response to the EHLO command with the STREAM
keyword, the MAIL FROM and RCPT TO commands can optionally be
sent as a block. If the MAIL FROM address is invalid or otherwise
unavailable, the following RCPT TO commands should be answered with
the 503 command out of sequence error.
Note: While SMTP does not explicitly require the stop and wait
behavior, and while the protocol as defined will work in a
streaming model, the examples have led implementors to build SMTP
servers in such a manner as to require this behavior. This
service extension recognizes the desire to use a streaming
implementation model and explicitly encourages its use.
Vaudreuil [Page 2]
Internet Draft Expires 4/18/94
6.Usage Examples
The following dialogue illustrates the use of the stream service
extension to send a 7BIT object to three recipients without the stop
and wait for an explicit 250 for each recipient:
S: <wait for connection on TCP port 25>
C: <open connection to server>
S: 220 cnri.reston.va.us SMTP service ready
C: EHLO ymir.claremont.edu
S: 250-cnri.reston.va.us says hello
S: 250 STREAM
C: MAIL FROM:<ned@ymir.claremont.edu>
C: RCPT TO:<vcerf@cnri.reston.va.us>
C: RCPT TO:<gvaudre@cnri.reston.va.us>
C: RCPT TO:<jstewart@cnri.reston.va.us>
S: 250 <ned@ymir.claremont.edu>... Sender ok
S: 250 <vcerf@cnri.reston.va.us>... Recipient ok
S: 250 <gvaudre@cnri.reston.va.us>... Recipient ok
S: 250 <jstewart@cnri.reston.va.us>... Recipient ok
C: DATA
S: 354 Send message, terminated by a dot.
...
.
S: 250 OK
C: QUIT
S: 250 Goodbye
7.Security Considerations
This RFC does not discuss security issues and is not believed to raise
any security issues not already endemic in electronic mail and present
in fully conforming implementations of [1].
8.Acknowledgements
This document is the result of numerous discussions in the IETF SMTP
Extensions Working Group. Text for this document was liberally copied
from RFC 1426 by John Klensin, Marshall Rose, Need Freed, Dave
Crocker, and Einar Stefferud.
Vaudreuil [Page 3]
Internet Draft Expires 4/18/94
9.References
[1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
USC/Information Sciences Institute, August 1982.
[2] Crocker, D., "Standard for the Format of ARPA Internet Text
Messages", STD 11, RFC 822, UDEL, August 1982.
[3] Borenstein, N., and N. Freed, "Multipurpose Internet Mail
Extensions", RFC 1341, Bellcore, Innosoft, June 1992.
[4] Klensin, J., WG Chair, Freed, N., Editor, Rose, M.,
Stefferud, E., and D. Crocker, "SMTP Service Extensions" RFC
1425,
[5] Klensin, J., WG Chair, Freed, N., Editor, Rose, M.,
Stefferud, E., and D. Crocker, "SMTP Service Extension for 8bit-
MIMEtransport" RFC 1426, United Nations University, Innosoft
International, Inc., Dover Beach Consulting, Inc., Network
Management Associates, Inc., The Branch Office, February 1993.
10. Author's Address
Gregory M. Vaudreuil
The Tigon Corporation
17080 Dallas Parkway
Dallas, TX 75248-1905
214-733-2722
Gvaudre@cnri.reston.va.us
Vaudreuil [Page 4]